NXcomponent as a parent base class
#1525
Conversation
|
Quick comment that I missed to mention in today's telco: are there any tools that would expect these classes to extend We had a similar problem before when we tried to subclass Since base class inheritance is now supported, such checks will anyway break on a smaller scale, e.g. for |
|
The question of whether there are tools to implement inheritance is impossible to answer. I can modify the That is one reason I have argued in the past for a package like |
|
As suggested in #1408 (comment), here is a flow diagram with the new inheritance (not containing changes to the contributed definitions).
|
|
I also added |
|
Removed |
|
Hi all, as discussed in the Telco, we can now move this PR to an online vote. NIAC committee members please vote on this PR using emojis on this comment. 👍 for yes, 👎 for no, anything else (for example 👀) to abstain. We need 14 votes to hit quorum so please review and vote! |
| </doc> | ||
| <field name="applied" type="NX_BOOLEAN"> | ||
| <doc> | ||
| Was the component used? |
There was a problem hiding this comment.
This description is somewhat vague: what does "used" mean, in this context?
| extending ``NXcomponent``) or ``NXbeam`` that act as input(s) to this | ||
| component. | ||
|
|
||
| Each input should point to the path of the group acting as input. |
There was a problem hiding this comment.
This description leaves me with a number of questions:
Where is the format for a path defined? Can the path be absolute, can it be relative?
How are the paths within the list concatenated into a single string? (space-separated list? comma-separated list? colon-separated list?) If paths have separator character, is white space allowed (or required) around separator character?
Is there an escaping mechanism? One of the paths in the list might contain a path-separator character. Without escaping, this could lead to ambiguity.
Is there any significance placed on the order of paths within this list?
The approach of serialising paths seems to be reimplementing HDF5's symlink feature. Why not just use symlinks, instead?
| extending ``NXcomponent``) or ``NXbeam`` that act as output(s) of this | ||
| component. | ||
|
|
||
| For more information, see :ref:`inputs </NXcomponent/inputs-field>`. |
There was a problem hiding this comment.
The description leaves me with the same questions as with the inputs field.
| --> | ||
| <definition xmlns="http://definition.nexusformat.org/nxdl/3.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" category="base" type="group" name="NXcomponent" extends="NXobject" xsi:schemaLocation="http://definition.nexusformat.org/nxdl/3.1 ../nxdl.xsd"> | ||
| <doc> | ||
| Base class for components of an instrument - real ones or simulated ones. |
There was a problem hiding this comment.
I would suggest also mentioning that a NXcomponent has some well-defined position in space.
|
Just to be clear: I really like the idea behind this PR and would like to see this go into NeXus. However, I'd like the descriptions to be improved; in particular, the comments for the "inputs" field. |
Disclaimer: This is a draft and not meant to be voted on yet. The idea here is to perform an exploration/survey of the consequences of what having an
NXcomponentbase class would mean.This implements the discussion items in #1519 (comment).
NXcomponentis meant as a parent base class that many base classes describing devices/instrument components should derive from. As requested in the comment above, this is meant as a survey of base classes to identify those which should and those which should not derive fromNXcomponent.These are the base classes that are now inheriting from NXcomponent:
in
base_classes:in
contributed_definitions:In addition, the
defaultattribute is added toNXobjectso that it doesn't have to be repeated in every class. As a consequence, it can be removed This affects almost all of the classes above, but additionally the default attribute is removed from these classes (which are still inheriting from NXobject, not from NXcomponent):further changes:
Open questions: